IMS MFS (message format service) metamodel

ABSTRACT

A method of and a system for processing an enterpise an application request on an end user application and an application server. This is accomplished by initiating the application request on the end user application in a first language (such as a markup language) with a first application program (such as a Web browser), and transmitting the application request to the server and converting the application from the first language of the first end user application to a language running on the application server, processing the application request on the application server, and transmitting the response from the application server back to the end user application, and converting the response from the language running on the application server to the language of the end user application. The end user application and the application server have at least one connector between them, and the steps of (i) converting the application request from the language of the end user application (as a source language) to the language running on the application server (as a target language), and (ii) converting the response to the application request from the language running on the application server (as a source language) to the language of the end user application (as a target language), each include the steps of invoking connector metamodels of the respective source and target languages, populating the connector metamodels with metamodel data of each of the respective source and target languages, and converting the source language to the target language.

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit under Title 35, United StatesCode, Sections 111(b) and 119(e), relating to Provisional PatentApplications, of the filing date of United States Provisional PatentApplication Serial Number 60/223,671 filed Aug. 8, 2000 of Steven A.Brodsky and Shyh-Mei Ho for EAI Common Application Metamodel.

[0002] This application is also related to the following United StatesPatent Applications, filed on even date herewith:

[0003] COMMON APPLICATION METAMODEL by Shyh-Mei Ho, Stephen Brodsky, andJames Rhyne,

[0004] COBOL METAMODEL by Shyh-Mei Ho, Nick Tindall, James Rhyne, TonyTsai, Peter Elderon, and Shahaf Abileah.

[0005] PL/I METAMODEL by Shyh-Mei Ho, Peter Elderon, Eugene Dong andTony Tsai.

[0006] HIGH LEVEL ASSEMBLER METAMODEL by Shyh-Mei Ho, John Ehrman,Benjamin Sheats, and Jenny Hung.

[0007] TYPE DESCRIPTOR METAMODEL by Shyh-Mei Ho, James Rhyne, PeterElderon, Nick Tindal, and Tony Tsai.

[0008] IMS TRANSACTION MESSAGES METAMODEL by Shyh-Mei Ho and ShahafAbileah

[0009] CICS-BMS (BASIC MESSAGE SERVICE) METAMODEL by Shyh-Mei Ho, AndyKrasun, and Benjamin Sheats.

FIELD OF THE INVENTION

[0010] The invention relates to exchanging instructions and/or databetween applications to signal readiness to transfer, exchange, orprocess data, or to establish at least one or more parameters fortransferring data between the applications, and controlling theparameters in order to facilitate data transfer and communication. Theinvention further relates to integrating dissimilar applications oneexecuting within one platform and another executing in another platform,e.g., multiple computers, multiple operating systems, multipleapplication components, multiple development environments, multipledeployment environments, or multiple testing and processing,establishing a dialog (e.g., a negotiation) with one another in order toestablish connectivity for transferring data and/or instructions betweenthe applications so as to facilitate performing tasks on the data orportions thereof to accomplish an overall goal. The parameters mayinclude one or more of format, data types, data structures, or commands.

BACKGROUND

[0011] The growth of e-business has created a significant need tointegrate legacy applications and bring them to the Internet This isbecause the current trend for new applications is to embrace Webstandards that simplify end user application construction andscalability. Moreover, as new applications are created, it is crucial toseamlessly integrate them with existing systems while facilitating theintroduction of new business processes and paradigms.

[0012] Integrating new applications with existing applications isespecially critical since industry analysts estimate that more thanseventy percent of corporate data, including data highly relevant toe-commerce, lives on mainframe computers. Moreover, while manye-commerce transactions are initiated on Windows, Mac, and Linux enduser platforms, using a variety of Web browsers, and go through WindowsNT and Unix servers, they are ultimately completed on mainframecomputers, running mainframe applications, and impacting data stored inmainframe databases.

[0013] There are e-business pressures to integrate server levelapplications and bring them to the Internet. However, there is nocomplete and easy mechanism to integrate or e-business enable theapplications. Integration, whether through messaging, procedure calls,or database queries, is key to solving many of today's businessproblems.

[0014] Integrating legacy applications with new software is a difficultand expensive task due, in large part, to the need to customize eachconnection that ties together two disparate applications. There is nosingle mechanism to describe how one application may allow itself to beinvoked by another.

[0015] One consequence is an e-commerce environment of multipleapplications, developed by multiple development teams, running ondifferent platforms, with different data types, data structures,commands, and command syntax's. This environment is stitched togetherwith application program interfaces and connectors. Connectors are anessential part of the total application framework for e-commerce.Connectors match interface requirements of disparate applications andmap between disparate interfaces.

[0016] This growing interconnection of old and new software systems andapplications, has led to various middle ware applications and connectorapplications, interface specifications, interface definitions, and code,especially for the interconnection and interaction of markup languages(such as HTML, XML, Dynamic HTML, WML, and the like), through objectoriented languages such as SmallTalk and C++, with languages of legacyapplication server applications (such as COBOL). These interfacespecifications, definitions, and code should apply across languages,tools, applications, operating systems, and networks so that an end userexperiences the look, feel, and responses of a single, seamlessapplication at her terminal. Instead, the proliferation of standards,protocols, specifications, definitions, and code, e.g., Common ObjectRequest Broker (CORBA), Common Object Model (COM), Object Linking andEmbedding (OLE), SOM, ORB Plus, Object Broker, Orbix, has insteadcreated an e-commerce “Tower of Babel.”

[0017] Examples of application integration are ubiquitous: frominstalling an ERP system, to updating an Operational Data Store (ODS)with IMS transactions or invoking CRM systems from MQSeries; each ofthese requires the same basic steps. First, a user must find the entityshe wants to communicate with, then she must figure out how to invokethe entity, and finally she must provide translation from one nativerepresentation to another. Today, these steps usually require manualinvestigation and hand coding—and leave the developers with a rat's-nestof hard-to-maintain connections between applications.

[0018] Attempts to remedy this situation involve application programinterfaces and connectors, which are frequently built on InterfaceDefinition Languages. Interface Definition Languages are declarative,defining application program interfaces, and, in some cases, issues suchas error handling. Most Interface Definition Languages are a subset ofC++, and specify a component's attributes, the parent classes that itinherits from, the exceptions that it raises, the typed events that itemits, the methods its interface supports, input and output parameters,and data types. The goal of Interface Definition Languages withinconnectors is to enable collaboration between dissimilar applicationswithout hard coded application program interfaces.

[0019] Ideally, the interface definition language, and the connector ofwhich it is a part, should facilitate full run-time software applicationcollaboration through such features as

[0020] Method invocation with strong type checking,

[0021] Run-time method invocation with greater flexibility and run timebinding,

[0022] High level language binding, with the interface separated fromthe implementation.

[0023] An interface repository containing real time information ofserver functions and parameters.

[0024] Additionally, the connector and its interface definitionlanguage, should be fast, efficient, scalable, portable, supportmetaclasses, support syntactic level extensions, and support semanticlevel extensions.

SUMMARY OF THE INVENTION

[0025] The problems associated with integrating new applications, forexample, e-commerce applications, with legacy applications are obviatedby the Common Application Metamodel tool, method, and system describedherein. The Common Application Metamodel method, tool, and system of theinvention facilitate tooling solutions, data translation, andcommunication and collaboration between dissimilar and disparateapplications, as well as full run-time software applicationcollaboration through an interface with the application server interfacedomain. This is accomplished through metadata interchange information,method invocation with strong type checking, run-time method invocation,run time binding, and high level language binding, with the interfaceseparated from the implementation, and an interface repositorycontaining real time information of client and server interfaceparameters.

[0026] Additionally, the tool, method, and system of the inventionprovide fast, efficient, and scalable interconnectivity independently ofany tool or middleware, are reusable and portable, and supportmetaclasses, syntactic level extensions, and semantic level extensions,and are independent of any particular tool or middleware.

[0027] The Common Application Metamodel tool, method, and system isespecially useful for providing a data transformer that isbi-directional between a client application and a server application,transmitting commands and data both ways between, for example, a Java,HTML, XML, C, or C++ application and a COBOL, PL/I, or High LevelAssembler application, or, between an HTML or XML application and aJava, C, or C++ application, or between a Java application and a C orC++ application.

[0028] In a preferred embodiment of the invention, the metamodel is usedin an transaction message management environment for processing anapplication request on an end user application and an application serverwhere the server a transaction message formatter. In this embodiment anapplication request is initiated on the end user application in a firstlanguage with a first application program, and transmitted to the serverwhere it is converted from the first language of the first end userapplication to a form for the transaction message formatter running onthe application server. The application request is processed on theapplication server and a response is transmitted from the applicationserver to the end user application. The response to the applicationrequest is converted from the language and form of transaction messageformatter running on the application server to the first language of thefirst end user application. The end user application and the applicationserver have at least one connector therebetween. In this way steps of(i) converting the application request from the first language of thefirst end user application as a source language to the language(including the form of the transaction message message formatter)running on the application server as a target language, and (ii)converting a response to the application request from the language(including the form of the transaction message message formatter)running on the application server as a source language to the firstlanguage of the first end user application as a target language, eachcomprise the steps of: invoking connector metamodels of respectivesource language and target transaction message formatter; populating theconnector metamodels with metamodel data of each of the respectivesource language and target transaction message formatter, the metamodeldata of the target transaction message formatter including a messagedescriptor, logical page, password, segment, message field, devicedescriptor, device type, device division, device page and device field;and converting the source language to the transaction message formatter.To be noted is that the metamodel data of the target transaction messageformatter includes a message descriptor, logical page, password,segment, message field, device descriptor, device type, device division,device page and device field.

[0029] One embodiment of the invention is a method of processing atransaction on or between an end user application and one or moreapplication servers. The method comprises the steps of initiating thetransaction on the end user application in a first language with a firstapplication program, transmitting the transaction to the server, andconverting the transaction from the first language of the first end userapplication to a language running on the application server. Typically,as described above, the client will be a thin client or a Web browser,the application running on the client will be a Web browser applicationor a thin client connectivity application, and the language of theclient application will be Java, C, C++, or a markup language, as HTMLor a derivative of HTML, such as XML or Dynamic HTML or WML, or thelike, and the language running on the server may be COBOL, PL/I, HLASM(High Level Assembler) or the like. The invention facilitatestransformers which convert the transaction from the first language ofthe end user application to a language running on the applicationserver. After conversion, the converted transaction is processed on theapplication server.

[0030] The application processes the request and then sends the responsefrom the application server back to the end user application. Typically,as described above, the application server will be running a COBOL basedapplication, and the client will be a thin client written in Java or Cor C++, or a Web browser, running a Web browser application or a thinclient connectivity application, in a markup language, as HTML or aderivative of HTML, such as XML or Dynamic HTML, or the like. Theinvention provides data transformers which convert the response from thelanguage or languages running on the application server or servers tothe first language of the first end user application.

[0031] The end user application and the application server have at leastone data transformer between them. In this way, the steps of (i)converting the request from the first language of the first end userapplication as a source language to the language running on anapplication server as a target language, and (ii) converting theresponse from the language running on the application server, as asubsequent source language, back to the first language of the first enduser application, as a subsequent target language, each comprise thesteps of invoking type descriptor and language metamodels of respectivesource and target languages, populating the metamodels with each of therespective source and target languages' data items and types, andconverting the source language to the target language.

[0032] The end user application is, frequently, a web browser or a thinclient. When the end user application is a Web browser, the end user isconnected to the application server through a web server. According to afurther embodiment of the invention, the web server may comprise theconnector, or data transformer. The data transformer integrated with theWeb server may directly convert the request, transaction, or messagefrom a browser oriented form to an application server language or to anintermediate, business or commerce oriented markup language, such asXML.

[0033] The CAM metamodel used to construct the converter comprises aninvocation metamodel, an application domain interface metamodel, alanguage metamodel, and a type descriptor metamodel. Exemplaryinvocation metamodel includes information chosen from the groupconsisting of message control information, security data, transactionalsemantics, trace and debug information, pre-condition and post-conditionresources, and user data, etc. Exemplary application domain interfacemetamodel comprises information chosen from input parameter signatures,output parameter signatures, and return types. Application domaininterface metamodel uses one or more language metamodels, such as COBOLand PL/I metamodels.

[0034] The type descriptor metamodel defines physical realizations,storage mapping, data types, data structures, and realizationconstraints.

[0035] The method of the invention is applicable to situations where oneof the source or target languages is object oriented, and the other ofthe target or source languages is not object oriented. In thissituation, the language metamodel and the type descriptor metamodeltogether map encapsulated objects of the object oriented language intocode and data of the language that is not object oriented. Additionally,the language metamodel and the type descriptor metamodel maps objectinheritances of the object oriented language into references andpointers in the language that is not object oriented. The method of theinvention is also applicable to situations where different objectoriented languages are running on different platforms, and encapsulatedobjects of the source language (code and data) are mapped intoencapsulated objects of the target language. The method of the inventionis also applicable where different procedural languages are running ondifferent platforms or applications and commands and data of the sourceprocedural language are mapped into the target procedural language.

[0036] According to the method of the invention, there may be aplurality of applications for vertical (sequential, conditional, ordependent) processing, for horizontal (parallel in time) processing, orboth horizontal and vertical processing. This is to support richtransactions to and through multiple hierarchical levels and multipleparallel sequences of processing. This may be the case in business tobusiness transactions drawing upon financial, manufacturing, scheduling,supply, and shipping databases and servers, and utilizing variouscommercial security instruments.

[0037] A further aspect of the invention is a client-server processingsystem having a client, a server, and at least one transformer betweenthe client and one or more servers,

[0038] A still further aspect of the invention is a processing systemconfigured and controlled to interact with a client application. In thisaspect of the invention, the system comprises, a server, and at leastone transformer between the server and the client application, where theclient has an end user application, and is controlled and configured toinitiate a request with the server in a first language with a firstapplication program and to transmit the request through a transformer tothe server or servers. The server processes the request in a secondsoftware application, using a second language, and returns a response tothe client through a transformer.

[0039] A further aspect of the invention is a groupware system having aplurality of e-mail enabled end user applications, such as e-mail, wordprocessing, spreadsheet, simple database management (such as LotusApproach or Microsoft Access), graphics and graphics editing, audio andaudio editing, and computer-telephony integration (“CTI”), along withclient level content database client services and content replicationclient services. Groupware integrates these e-mail enabled applicationsthrough one or more transformers and application program interfaces withtransport services, directory services, and storage services, includingcontent servers and replication servers. The groupware system isconfigured and controlled to communicate among disparate end userapplications, among disparate servers, and between disparate servers andend user applications. The groupware system comprises at least onetransformer between a server and an end user application. The end userapplication is controlled and configured to participate with a server ina first language of a first application program and the server isconfigured and controlled to participate with the client in a secondlanguage of a second program.

[0040] The transformer is configured and controlled to receive a requestfrom the end user application, and convert the request from the firstlanguage of the first end user application to a language running on theserver. The server is configured and controlled to receive the convertedrequest from the transformer and process the request in a secondlanguage with a second application program residing on the server, andto thereafter transmit a response through a transformer back to the enduser application.

[0041] A still further embodiment of the invention is the provision ofrich transaction processing. Rich transactions are nested transactionsthat span to, through, and/or across multiple servers. The spanningacross nested servers may be horizontal, that is parallel dependenttransactions, or vertical, that is, serial dependent transactions. Richtransactions may be long lived, on-going transactions, or complexbusiness-to-business transactions, especially those with multipledependencies or contingencies, volume and prompt payment discounts, latedelivery and late payment penalties, and with financial processing, suchas electronic letters of credit, electronic bills of lading, electronicpayment guarantees, electronic payment, escrow, security interests inthe goods, and the like. In a rich transaction environment, sometransaction servers may be positioned as clients with respect to othertransactions for certain sub transactions making up the richtransaction.

[0042] A still further embodiment of the invention is a tool, that is, asoftware developer's kit, characterized in that the program product is astorage medium (as a tape, floppy disks, a CD-ROM, or a hard drive orhard drives on one of more computers) having invocation metamodels,application domain interface metamodels, and language metamodels, andcomputer instructions for building a metamodel repository of source andtarget language metamodels. The program product also contains computerinstructions for building connector stubs from the metamodels. Theprogram product further carries computer instructions to build atransformer.

[0043] While the invention has been described in summary form as havinga single level of connectors, it is, of course, to be understood thatsuch connectors may be present at various levels in the processinghierarchy, for example between Web Clients and Web servers, between webservers and application servers, between application servers anddatabase servers, and between application servers or database servers orboth and various specialized repositories.

[0044] It is also to be understood, that while the invention has beensummarized in terms of individual clients and individual servers, theremay be multiple clients, multiple servers, and applications thatfunction as both clients and servers, as exemplified by groupwareapplications, and there might be multiple parallel lines and/or multiplehierarchical levels of application servers, data servers, and databases,as in systems for rich transactions.

THE FIGURES

[0045] Various elements of the invention are illustrated in the FIGURESappended hereto.

[0046]FIG. 1 illustrates a system with multiple application components,including a Netscape Internet Explorer browser, Net.Commerce on a SunSolaris server, Oracle and DB2 on a database server, SAP running on AIX,a CICS 390 server, an IMS 390 server, DB2 and DL/I on a S/390 platform,a Windows 200 client, and Baan running on an HP Unix server.

[0047]FIG. 2 illustrates the roles of message sets, SQL storedprocedures, legacy applications, and programming languages as inputs tothe metadata repository of the Common Application Metamodel tofacilitate enterprise application integration at run time.

[0048]FIG. 3 illustrates that the Common Application Metamodel of theinvention consists of three kinds of metamodels, i.e., an invocationmetamodel, an application-domain interface metamodel, and a languagemetamodel. For any given application-domain metamodel it may use one ormany language metamodels, and there could be zero or many invocationmetamodels.

[0049]FIG. 4 illustrates an IMS OTMA metamodel, with an OTMA InvocationMetamodel, an IMS Transaction Message Metamodel application interface,which could use a COBOL Metamodel, a C Metamodel, or other languagemetamodels.

[0050]FIG. 5 illustrates how a tool can be used to generate an XMLdocument describing application program interface. First, an objectmodel, i.e., a CAM metamodel, is created to capture interfacedefinitions about an application server. Then a tool reads and parsesthe source definitions of an application program and generates an XMLdocument by retrieving the object model's information from a repository.

[0051]FIG. 6 illustrates a development phase scenario where a CommonApplication Metamodel Rose file, e.g., a COBOL metamodel, a PL/Imetamodel, an MFS metamodel, a BMS model, or the like is read into atoolkit, to generate a DTD and XML schema and Java code for a Rosemodel. A source file of an application, as a COBOL source file, a PL/Isource file, an MFS source file, a BMS source file, or the like, is readinto an importer. The importer parses the source code and generates, asoutput, an XMI instance file, i.e., XML documents, by reading in theJava code of the Rose model of the application source files.

[0052]FIG. 7 illustrates a metamodel for application interfaces, whichenables integration of application components into an event basedmessaging model, including flow models. The flow and messaging middleinvokes applications through the application interface. These interfacesare access points to the applications through which all input and outputis connected to the middleware. The interfaces are described in terms ofthe Application Interface Metamodels. Transformation processingaccording to he metamodel could take place in source/clientapplications, target applications, or a gateway.

[0053]FIG. 8 illustrates the application of the Common ApplicationMetamodel during execution time. As shown, the CAM model facilitatesconnectivity between a back-end IMS application and a Web file (e.g.,SOAP complaint XML documents). This is accomplished by using informationcaptured in the model to perform data transformations from one platformto another in a mixed language environment shown.

[0054]FIG. 9 illustrates a MFS language metamodel, which is usable byapplication programs to define data structures which represent connectorinterfaces.

[0055]FIG. 10 illustrates the associations between the classes of theMFS metamodel.

[0056]FIG. 11 illustrates enumerations of Mode Values, Base Values,LengthTypes, and StringTypeValues for the MFS Metamodel.

DETAILED DESCRIPTION OF THE INVENTION

[0057] Definitions. As used herein the following terms have theindicated meanings. “Handshaking” is the exchange of information betweentwo applications and the resulting agreement about which languages,capabilities, and protocols to use that precedes each connection.

[0058] An “application program interface” (API) is a passive specificmethod prescribed by a computer operating system or by anotherapplication program by which a programmer writing an application programcan make requests of the operating system or another application.Exemplary is SAX (Simple API for XML), an connector that allows aprogrammer to interpret a Web file that uses the Extensible MarkupLanguage, that is, a Web file that describes a collection of data. SAXis an event-driven interface. The programmer specifies an event that mayhappen and, if it does, SAX gets control and handles the situation. SAXworks directly with an XML parser.

[0059] A “connector” as used herein is a dynamic, run-time, interfacebetween platforms that stores the functions and parameters of the targetplatform or program, and binds with the target platform program in realtime.

[0060] A “stub” is a small program routine that provides staticinterfaces to servers. Precompiled stubs define how clients invokecorresponding services on the server. The stub substitutes for a longerprogram on the server, and acts as a local call or a local proxy for theserver object. The stub accepts the request and then forwards it(through another program) to the remote procedure. When that procedurehas completed its service, it returns the results or other status to thestub which passes it back to the program that made the request. Serverservices are defined in the stub using an Interface Definition Language(“IDL”). The client has an IDL stub for each server interface that itaccesses and includes code to perform marshaling. Server stubs providestatic interfaces to each service exported by the server. “CICS”(Customer Information Control System) is the online transactionprocessing program from IBM that, together with the Common BusinessOriented Language programming language, is a set of tools for buildingcustomer transaction applications in the world of large enterprisemainframe computing. Using the programming interface provided by CICS towrite to customer and other records (orders, inventory figures, customerdata, and so forth) in a CICS, a programmer can write programs thatcommunicate with online users and read from a database (usually referredto as “data sets”) using CICS facilities rather than IBM's accessmethods directly. CICS ensures that transactions are completed and, ifnot, it can undo partly completed transactions so that the integrity ofdata records is maintained. CICS products are provided for OS/390, UNIX,and Intel PC operating systems. CICS also allows end users to use IBM'sTransaction Server to handle e-business transactions from Internet usersand forward these to a mainframe server that accesses an existing CICSorder and inventory database.

[0061] “IMS” (Information Management System) is the system from IBMthat, together with IBM's Enterprise Systems Architecture (IMS/ESA)provides a transaction manager and a hierarchical database server.

[0062] “MQ” is the MQSeries IBM software family whose components areused to tie together other software applications so that they can worktogether. This type of application is often known as businessintegration software or middleware. Functionally, MQSeries provides acommunication mechanism between applications on different platforms, anintegrator which centralizes and applies business operations rules, anda workflow manager which enables the capture, visualization, andautomation of business processes. MQSeries connects different computersystems, at diverse geographical locations, using dissimilar ITinfrastructures, so that a seamless operation can be run. IBM's MQSeriessupplies communications between applications, and between users and aset of applications on dissimilar systems. Additionally, MQSeries'messaging scheme requires the application that receives a message toconfirm receipt. If no confirmation materializes, the message is resentby the MQSeries.

[0063] “Rose” is an object-oriented Unified Modeling Language (UML)software design tool intended for visual modeling and componentconstruction of enterprise-level software applications. It enables asoftware designer to visually create (model) the framework for anapplication by blocking out classes with actors (stick figures), usecase elements (ovals), objects (rectangles) and messages/relationships(arrows) in a sequence diagram using drag-and-drop symbols. Rosedocuments the diagram as it is being constructed and then generates codein the designer's choice of C++, Visual Basic, Java, Oracle8, Corba orData Definition Language.

[0064] Common Application Metamodel Overview. The Common ApplicationMetamodel (CAM) brings interconnectivity to the environment illustratedin FIG. 1. FIG. 1 illustrates a typical system 101 with multipleapplication components, including a Netscape Internet Explorer browser103, Net.Commerce 105 on a Sun Solaris server 107, Oracle 109 and DB2111 on a database server 113, SAP 115 running on AIX 117, a CICS 390server 119, an IMS 390 server 121, DB2 123 and DL/I 125 on a S/390platform 127, a Windows 2000 client 129, and Baan 131 running on an HPUnix server 133. The Common Application Metamodel (CAM) is metadatainterchange method, tool, and system for marshaling and applyinginformation needed for accessing enterprise applications, such as inFIG. 1, in a source language and converting them to a target language.CAM consists of language metamodels and application domain interfacemetamodels, as shown in FIG. 2, which illustrates the roles of messagesets 203, SQL stored procedures 205, legacy applications 207, andprogramming languages 209 as inputs to the metadata repository 211 ofthe Common Application Metamodel to facilitate enterprise applicationintegration 221. Exemplary metamodels include C, C++, Java, COBOL, PL/I,HL Assembler, IMS transaction messages, IMS MFS, CICS BMS, and MQSeriesmessages models, as shown in FIG. 3, which illustrates the CommonApplication Metamodel of the invention, with an invocation metamodel301, an application-domain interface metamodel 303, and a languagemetamodel 305.

[0065]FIG. 4 illustrates an IMS OTMA application interface metamodel411, with an OTMA Invocation Metamodel 421, an IMS Transaction MessageMetamodel 423, a COBOL Metamodel 425, and a C Metamodel 427.

[0066]FIG. 5 illustrates the flow of information from an existingapplication 501, through an interface 503 to an object model containingapplication interface metadata. This application interface metamodel isstored in the metadata repository 505, and, at an appropriate time,retrieved from the metadata repository 505, combined with a sourceprogram 507 in a generation tool 509, and used to generate a target file511, as an XML file, i.e., an XMI instance file. CAM is highly reusableand independent of any particular tool or middleware.

[0067] Development Stage. With CAM, tooling can now easily providesolutions to access enterprise applications, e.g. IMS applications. Byparsing each source file and generating XML documents based on the CAMmodel, COBOL copybook, PL/I copybook, MFS Source, BMS Source, etc.,tools can provide connector solutions to IMS, and CICS, etc.

[0068] In this regard, FIG. 6 illustrates a development phase scenariowhere a Common Application Metamodel Rose file 601, e.g., a COBOLmetamodel, a PL/I metamodel, an MFS metamodel, a BMS model, or the likeis read into a toolkit 603, to generate a DTD and schema for a Rosemodel and Java code for a Rose model 605. A source file of anapplication 607, as a COBOL source file, a PL/I source file, an MFSsource file, a BMS source file, or the like, and the Java code for theRose model 609 are read into an Importer 611. The importer parses thesource code and provides, as output, an XMI instance file 613, i.e., XMLdocuments, of the application source files.

[0069]FIG. 7 shows a CAM metamodel for application interfaces. ThisFigure depicts a runtime connector 701 with invocation andtransformation capabilities, interfacing with an existing applicationprogram 703 through an interface 705 containing the existing applicationprogram's interface definition, in accordance with the applicationinterface metamodel 707. The Application Interface metadata is stored ina metadata repository 709.

[0070] The flow and messaging middleware 713 invokes applications 703through the application interfaces 705. These interfaces 705 are theaccess points to the applications 703 through which all input and outputis connected to the middleware 713. The interfaces 705 are described interms of the Application Interface Metamodel. Transformation processingaccording to the metamodel could take place in source/clientapplications, target applications, or a gateway.

[0071] Because CAM also provides physical representation of data typesand storage mapping to support data transformation in an enterpriseapplication integration environment, it enables Web services forenterprise applications. At development time CAM captures informationthat facilitates:

[0072] a). connector and/or connector-builder tools,

[0073] b). data driven impact analysis for application productivity andquality assurance, and

[0074] c). viewing of programming language data declarations bydevelopers.

[0075] The CAM metamodel files are inputs to toolkits used to generateDTD files, XML schemas, and Java classes which represent the CAM model.Importers parse each source file (e.g. COBOL or PL/I copybook, MFSsource, and BMS, etc.), and then generate XML documents (i.e. XMLinstance files) based on Java classes generated by the XMI/MOF2 toolkit.

[0076] Run Time. At run time CAM provides information which facilitatestransformation in an enterprise application integration environmentwhere it provides data type mapping between mixed languages, facilitatesdata translations from one language and platform domain into another.

[0077]FIG. 8 illustrates the application of the Common ApplicationMetamodel during run time. As shown, SOAP compliant XML documents 803are received in, for example, IBM WebSphere middleware, 805, whichcontains an IMSConnector for Java 807, and is in contact with an XMLRepository 809, containing the XMI instance files for the CAM model. TheIBM WebSphere middleware sends the transformed file to the IMS system811, which contains an instance of IMS Connect 813 and the IMStransactional application program 815. CAM facilitates connectivitybetween the back-end IMS application 815 and the Web file (e.g., SOAPcompliant XML documents) 803. The CAM accomplishes this by using CAMmodel information (from repository 809) to perform data transformationsfrom one platform to another in the mixed language environment shown.

[0078] Type Descriptor Metamodel. One important feature provided by CAMis the Type Descriptor metamodel. The Type Descriptor metamodel definesthe physical realization, storage mapping, and the constraints on therealization (such as justification). This metamodel provides a physicalrepresentation of individual fields of a given data structure. Whensupporting data transformation in an enterprise application integrationenvironment, the model provides data type mapping between mixedlanguages. It also facilitates data translations from one language andplatform domain into another. The metamodel is used for runtime datatransformation (or marshaling) with a language-specific metamodel foroverall data structures and field names.

[0079] 1. Common Application Metamodel for Application Interfaces

[0080] The interconnection of disparate and dissimilar applicationsrunning on different software platforms, as shown in FIG. 1, withdifferent operating systems, physical platforms, and physicalrealizations is accomplished through connectors that incorporate theinterconnection metadata. Connectors are a central part of theapplication framework for e-business. The end user demand is to connectto anything interesting as quickly, and as easily, as possible.

[0081] A connector is required to match the interface requirements ofthe adapter and the legacy application. It is also required to mapbetween the two interfaces. Standardized metamodels for applicationinterfaces presented herein allow reuse of information in multipleconnector tools. These standardized metamodels not only reduce work tocreate a connector, but also reduce work needed to develop connectorbuilder tools.

[0082] The connectors built using the common application metamodel ofour invention provide interoperability with existing applications. Theconnectors support leveraging and reuse of data and business logic heldwithin existing application systems. The job of a connector is toconnect from one application system server “interface” to another.Therefore, an application-domain interface metamodel describessignatures for input and output parameters and return types for a givenapplication system domain (e.g. IMS, MQSeries); it is not for aparticular IMS or MQSeries application program. The metamodel containsboth syntactic and semantic interface metadata.

[0083] 1. a. End-to-End Connector Usage Using Common ApplicationMetamodel

[0084] The Common Application Metamodel (CAM) consists ofmeta-definitions of message signatures, independent of any particulartool or middleware. Different connector builder tools can use thisinformation to ensure the “handshaking” between these applicationprograms, across different tools, languages, and middleware. Forexample, if you have to invoke a MQSeries application, you would need tobuild a MQ message using data from a GUI tool and deliver it using theMQ API. Similarly, when you receive a message from the MQSeriesapplication, you would need to get the buffer from MQSeries, parse itand then put it into a GUI tool data structure. These functions can bedesigned and implemented efficiently by a connector builder tool usingCAM as standardized metamodels for application interfaces.

[0085] CAM can be populated from many sources, including copy books, togenerate HTML forms and JavaServer Page (JSP) for gathering inputs andreturning outputs. An example of a connector as depicted in the previousfigure is that the flow and message middleware makes a function call toan enterprise application by calling the connector which then calls theenterprise application API. The connector does language and data typemappings, for example, to translate between XML documents and COBOLinput and output data structures based on CAM. Connectors and CAMprovide the end-to-end integration between the middleware and theenterprise applications.

[0086] Using IMS as an example. Let's say that you must pass an accountnumber to an IMS transaction application program from your desktop towithdraw $50.00. With CAM and a connector builder tool, you will firstgenerate an input HTML form and an output JSP; and develop a middlewarecode necessary to support the request. The desktop application fills therequest data structure (i.e. an input HTML form) with values and callsthe middleware. The middleware service code will take the data from theGUI tool, build an IMS Connect XML-formatted message, and deliver themessage to the IMS gateway (i.e. IMS Connect) via TCP/IP. IMS Connecttranslates between the XML documents and the IMS message data structuresin COBOL using the metadata definitions captured in CAM. It then in turnsends the IMS message data structures to IMS via Open TransactionManager Access (OTMA). The IMS COBOL application program runs, andreturns the output message back to the middleware service code via IMSConnect. The middleware service code gets the message and populates theoutput JSP page (i.e. previously generated GUI tool reply datastructures) with the reply data. The transaction output data will thenbe presented to the user.

[0087] 2. Common Application Metamodel

[0088] CAM is used to describe information needed to easily integrateapplications developed in common programming models with other systems.The CAM metamodel can be used for both synchronous and asynchronousinvocations.

[0089] 2. a. Common Application Metamodel

[0090] The common application metamodel depicted as follows consists ofan invocation metamodel and an application-domain interface metamodelwhich uses language metamodels. For any given application-domaininterface metamodel, it may use one or many language metamodels, but,there could be zero or more invocation metamodels.

[0091] The common connector metamodel is illustrated in FIG. 3. It hasan Invocation Metamodel 301, an Application-Domain Interface Metamodel303, and a Language Metamodel 305.

[0092] 2. a. i. Invocation Metamodel

[0093] The invocation metamodel 301 consists of one or more of thefollowing possible metadata elements. However, for a particularinvocation, it could include only one or many of the following metadataelements.

[0094] Message-control information. This includes message controlinformation, such as the message connection name, message type, sequencenumbers (if any), and various flags and indicators for response,commit-confirmation, and processing options by which a client or servercan control message processing to be synchronous or asynchronous, etc.

[0095] The connection name can be used by the application system serverto associate all input and output with a particular client. The messagetype specifies that the message is a response message; or that commit iscomplete. It can also indicate server output data to the client, orclient input data to the server. Security data—This includesauthentication mechanism, and security data, e.g. digital certificates,identity, user name and password, etc. It may also include authorizationinformation to indicate whether the data can be authorized via a rolebased or ACL (access control list) based authorization.

[0096] Transactional semantics—This will carry transaction information,e.g. local vs. global transaction; two-phase commit vs. one-phasecommit, and transaction context, etc.

[0097] Trace and debug—Trace and debugging information are specified aspart of the metamodel.

[0098] Precondition and post-condition resource—This describesapplication state precondition and post-condition relationships.

[0099] User data—This includes any special information required by theclient. It can contain any data.

[0100] 2. a. ii. Application-Domain Interface Metamodel

[0101] The application-domain interface metamodel 303, as discussedearlier, describes signatures for input and output parameters and returntypes for application system domains.

[0102] 2. a, iii. Language Metamodel

[0103] The language metamodel 305, e.g. COBOL metamodel, is used byenterprise application programs to define data structures (semantics)which represent connector interfaces. It is important to connector toolsto show a connector developer the source language, the target language,and the mapping between the two. The CAM language metamodel alsoincludes the declaration text in the model which is not editable (i.e.read-only model). Because the connector/adapter developer would probablyprefer to see the entire COBOL data declaration, including comments andany other documentation that would help him/her understand the businessrole played by each field in the declaration.

[0104] The language metamodel is also to support data driven impactanalysis for application productivity and quality assurance. (But, it isnot the intention of the CAM to support reproduction of copybooks.)

[0105] The language metamodels describing connector data are listed asfollows:

[0106] *C

[0107] *C++

[0108] *COBOL

[0109] *PL/I

[0110] 2. a. iv. Type Descriptor Metamodel

[0111] The Type Descriptor metamodel is language neutral and defines thephysical realization, storage mapping and the constraints on therealization such as justification. This metamodel provides physicalrepresentation of individual fields of a given data structure. The typedescriptor metamodel is to support data transformation in an enterpriseapplication integration environment to provide data types mappingbetween mix languages. It also facilitates data translations from onelanguage and platform domain into another. This metamodel will be usedas a recipe for runtime data transformation (or marshaling) withlanguage specific metamodel for overall data structures and fieldsnames.

[0112] 3. An Example of Common Connector Metamodel

[0113] IMS OTMA (Open Transaction Manager Access) is atransaction-based, connectionless client/server protocol within anOS/390 sysplex environment. An IMS OTMA transaction message consists ofan OTMA prefix, plus message segments for input and output requests.Both input and output message segments contain llzz (i.e. length of thesegment and reserved field), and application data. Only the very firstinput message segment will contain transaction code in front of theapplication data. IMS transaction application programs can be written ina variety of languages, e.g. COBOL, PL/I, C, and Java, etc. Therefore,the application data can be in any one of these languages.

[0114] As shown in FIG. 4, an IMS OTMA connector metamodel 401 iscomposed of an invocation metamodel 403 and an IMS transaction messagemetamodel 405, as well as a COBOL metamodel 407 and a C metamodel 409.As depicted in FIG. 4, the invocation metamodel 401 is the OTMA prefix,and the IMS transaction message metamodel 405 is the application-domaininterface metamodel for the IMS application system which uses languagemetamodels. Metamodels for COBOL 407 and C 409 are shown.

[0115] 4. Type Descriptor Metamodel

[0116] The type descriptor metamodel presents a language and platformindependent way of describing implementation types, including arrays andstructured types. This information is needed for marshaling and forconnectors, which have to transform data from one language and platformdomain into another. Inspections of the type model for differentlanguages can determine the conformance possibilities for the languagetypes. For example, a long type in Java is often identical to a binarytype (computational-5) in COBOL, and if so, the types may beinter-converted without side effect. On the other hand, an alphanumerictype in COBOL is fixed in size and if mapped to a Java type, loses thisproperty. When converted back from Java to COBOL, the COBOL truncationrules may not apply, resulting in computation anomalies. In addition,tools that mix languages in a server environment (e.g., Java and COBOLin CICS and IMS) should find it useful as a way to determine howfaithfully one language can represent the types of another.

[0117] Therefore, an instance of the type descriptor metamodel describesthe physical representation of a specific data type for a particularplatform and compiler.

[0118] 4. a. TDLang Metamodel

[0119] The TDLang metamodel serves as base classes to CAM languagemetamodels by providing a layer of abstraction between the TypeDescriptor metamodel and any CAM language metamodel. All TDLang classesare abstract and common to all the CAM language metamodels. Allassociations between TDLang classes are marked as “volatile,”“transient,” or “derived” to reflect that the association is derivedfrom the language metamodel. The TDLang model does not provide anyfunction on its own, but it is the type target for the association fromthe Type Descriptor metamodel to the language metamodels.

[0120]FIG. 9 illustrates the structure of the TDLang Metamodel, with theTDLangClassifier 501, the TDLangComposedType 503 and the TDLangElement505.

[0121] With the TDLang base classes, the Type Descriptor metamodel canbe used as a recipe for runtime data transformation (or marshaling) withthe language-specific metamodel for overall data structures and fieldnames, without duplicating the aggregation associations present in thelanguage model.

[0122] 4. b. Type Descriptor Metamodel

[0123] This metamodel is a MOF Class instance at the M2 level. FIG. 10shows the relationships within the type descriptor Metamodel, includingthe PlatformCompilerType 601, the InstanceTDBase 603, the ArrayTD 605,the AggregatelnstanceTD 607, the Simple InstanceTD 609, and theInstanceType 611. The InstanceType 611 comprises definitions of theStringTD 613, the AddressTD 615, the NumberTD 617, and the FloatTD 619.FIG. 11 illustrates a higher level view of the TDLanguageElement and thePlatformCompilerType 601. FIG. 12 illustrates enumerations of signCoding801, lengthEncoding 803, floatType 805, accessor 807, packedDecimalSign809, and bitModePad 811.

[0124] 4. c. Type Descriptor and Language models

[0125] The Type Descriptor model is attached to the CAM Language modelby a navigable association between TDLangElement and InstanceTDBase.TDLangElement is the base language model type used to represent adeclared data item, i.e., an instance of a type. InstanceTDBase is thebase Type Descriptor model type used to represent theimplementation-specific instance of this same declared data item.InstanceTDBase is abstract; only one of its subtypes may beinstantiated.

[0126] It is possible that a data item declared in a programminglanguage may have different implementations. These differences areinduced by hardware platform, system platform, and compiler differences.This possibility is modeled by the PlatformCompilerType model type. Theassociation between TDLangElement and PlatformCompilerType is many toone, and the association between PlatformCompilerType and InstanceTDBaseis one to one. To navigate from the language model, it is necessary toknow what PlatformCompilerType is to be assumed. It is possible that animplementation, upon importing a model instance, will wish to removefrom the model the PlatformCompilerType instances that are not ofinterest.

[0127] The association between TDLangElement and InstanceTDBase ismodeled in this manner to allow for extending the model to include anassociation between PlatformCompilerType and a new type that more fullydescribes the hardware platform, the system platform, and the compiler.

[0128] Data element instances may be defined as repeating groups orarrays. This is modeled as a one to many association betweenInstanceTDBase and the ArrayTD model type. There would be one ArrayTDinstance in this association for each dimension, subscript, orindependent index of the data element. These instances hold informationabout the bounds and accessing computations.

[0129] The association is ordered in the same order as the correspondingassociation in the language model, and reflects the syntactic orderingof the indices as defined by the programming language. The rationale forthis choice is the resulting equivalence of navigation and processingalgorithms between the language model and the Type

[0130] Descriptor model. Another choice, perhaps more advantageous tomarshaling engines, would be to have the ordering of the indices fromthe smallest stride to the largest. This allows a marshaling engine toprocess the array in its natural storage order, assuming it is laid outin the usual contiguous fashion. A marshaling engine can compute thisorder by re-sorting the association targets according to the strideformulas if desired.

[0131] Array information may be a complex property of the data elementor of its type, and various languages and programming practices seem tofall on either side. The typedef facility of C and C++ allows thedefinition of some array types from typedefs, but only where the arraydefinitions are applied to the topmost elements of typedef aggregates.For example, consider the following typedef: typedef struct { int A;struct { int C; char D; struct { int F; int G; } E; { B; { X;

[0132] This typedef can be used to create a new typedef for a fixed sizearray, e.g. typedef X Q[10];

[0133] But it is not possible to create a new typedef from X that makesany of the subcomponents of X, e.g., D or E, into an array. This exampleand many others point out the unclear status of array definitions intyped languages.

[0134] An InstanceTDBase type has two concrete subtypes,SimplelnstanceTD and AggregatelnstanceTD. SimplelnstanceTD models dataelements without subcomponents, while AggregatelnstanceTD models dataelements with subcomponents. To find the subcomponents of anAggregatelnstanceTD, one must navigate back to the corresponding dataelement declaration in the CAM language model. There, the associationbetween an aggregate type and its subcomponents may be navigated,leading to a set of subcomponent data elements, each of which has one ormore corresponding instances in the Type Descriptor model. Thisintroduces some model navigation complexity, but avoids duplicating theaggregation hierarchy in both the language and the Type Descriptormodels. The additional processing complexity of traversal is not great,and considerable simplification is obtained in algorithms that wouldmodify the model to add, delete or rearrange subcomponents in anaggregation.

[0135] A SimpleInstanceTD model type is also associated one to one witha BaseTD model type. The BaseTD model type is specialized to holdimplementation information that is common for all data elements of thesame language type. The information that describes a 32-bit signedbinary integer on a specific hardware/software platform is thusinstantiated only once in a given model instantiation, no matter howmany data elements may be declared with this type.

[0136] One may contemplate an association between TDLangClassifier andBaseTD matching the association between TDLangElement andInstanceTDBase. However, this is problematic in that constructions thatthe language regards as simple types (e.g., strings) may not mapdirectly to simple hardware/software types. Rather than introduce moremechanisms into the Type Descriptor model to describe stringimplementations, a specialization of BaseTD is utilized which describesthe common string implementations. Various attributes in theTypeDescriptor model are suffixed with the string “formula.” Theseattributes contain information that may in some cases be impossible tocompute without access to data created only at run-time. An example isthe current upper bound of a variable-sized array or the offset to anelement that follows another element whose size is only known atrun-time. Such information could be included as values in a modelinstance, but this would require a model instance for each run-timeinstance, and would mean that the model could only be constructed atrun-time, requiring the model definition to include factories and otherapparatus to create model instances at run-time. A model that can beconstructed from platform and compiler knowledge is much more useful,and the formulas provide a way to define concrete values when therun-time information is available. These formulas may be interpreted bymarshaling engines, or they may be used to generate marshaling code,which is loaded and executed by the marshaling engine on demand.

[0137] 5. Application-Domain Interface Metamodel IMS MFS (MessagingFormatting Service)

[0138]FIG. 9 illustrates a MFS language metamodel, which is usable byapplication programs to define data structures which represent connectorinterfaces. FIG. 10 illustrates the associations between the MFSmetamodel with the TDLang base classes which are the TDLangClassifier,the TDLanguageComposedType, and the TDLanguageElement for the MFSMetamodel. FIG. 32 illustrates enumerations of Mode Values, Base Values,LengthTypes, and StringTypeValues for the MFS Metamodel.

[0139] Package Documention for MFS

[0140] The following device types are supported:

[0141] 3270 and 3270-An

[0142] 3270P

[0143] The following device types are not supported:

[0144] 2740 or 2741

[0145] 3600 or 4700

[0146] FIN

[0147] FIDS, FIDS3, FIDS4 or FIDS7

[0148] FIJP, FIPB or FIFP

[0149] SCS1

[0150] SCS2

[0151] DPM-An

[0152] DPM-Bn

[0153] Statements implicitly supported through parser:

[0154] ALPHA

[0155] COPY

[0156] DO

[0157] END

[0158] ENDDO

[0159] EQU

[0160] FMTEND

[0161] MSGEND

[0162] RESCAN

[0163] TABLEEND

[0164] Tolerated statements:

[0165] EJECT

[0166] PD

[0167] PDB

[0168] PDBEND

[0169] PPAGE

[0170] PRINT

[0171] RCD

[0172] SPACE

[0173] STACK

[0174] TITLE

[0175] UNSTACK

[0176] MFSDeviceType

[0177] DEV statement

[0178] The DEV statement defines device characteristics for a specificdevice or data formats for a specific device type. The DFLD statementsfollowing this DEV statement are mapped using the characteristicsspecified until the next DEV or FMTEND statement is encountered.

[0179] Unsupported attributes:

[0180] ERASE

[0181] FTAB

[0182] FORMS

[0183] HT

[0184] HTAB

[0185] LDEL

[0186] MODE

[0187] SLD

[0188] VERSID

[0189] VT

[0190] VTAB

[0191] Derived from MFSStatement

[0192] Private Attributes:

[0193] card:String

[0194] CARD attribute

[0195] Defines the input field name to receive operator identificationcard data when that data is entered. This name can be referenced by anMFLD statement and must not be used as the label of a DFLD statementwithin this DEV definition. This operand is valid only if a 3270 displayis specified. If FEAT=NOCD is specified for a 3270 display, it ischanged to CARD. All control characters are removed from magnetic cardinput before the data is presented to the input MFLD that refers to thiscard field name.

[0196] For 3270 displays, an unprotected field large enough to containthe magnetic card data and control characters must be defined through aDFLD statement. Position the cursor to this field and insert the card inthe reader to enter card information. The card data is logicallyassociated with the CARD=field name, not the name used in the DFLDstatement.

[0197] dsca:String

[0198] DSCA attribute

[0199] Specifies a default system control area (DSCA) for outputmessages using this device format. The DSCA supersedes any SCA specifiedin a message output descriptor if there are conflicting specifications.Normally, the functions specified in both SCAs are performed. If theDSCA=operand is specified for 3270P, it is ignored, except for the bitsetting for “sound device alarm.” If this bit is specified on theDSCA/SCA option, it is sent to the device.

[0200] The value specified here must be a decimal number not exceeding65535 or X‘hhhh’. If the number is specified, the number is internallyconverted to X‘hhhh’.

[0201] If byte 1 bit 5 is set to B‘1’ (unprotect screen option) for a3275 display, and both input and output occur simultaneously(contention), the device is disconnected. For non-3275 devices, the SCAoption is ignored. If byte 1 bit 5 is set to B‘0’, the applicationprogram can request autopaged output by setting the SCA value to B‘1’.This request is honored only if present in the first segment of thefirst LPAGE of the output message.

[0202] If a nonzero value is specified for byte 0, or for bit 6 or 7 inbyte 1, MFS overrides the specified value with zero.

[0203] features:MFSFeatureType

[0204] FEAT attribute

[0205] Specifies features for this device or program group.

[0206] IGNORE

[0207] Specifies that device features are to be ignored for this device.

[0208] 120|126|132

[0209] Specifies line length for 3284, and 3286 device types(TYPE=3270P).

[0210] CARD

[0211] Specifies that the device has a 3270 operator identification cardreader.

[0212] NOCD specifies the absence of the CARD feature.

[0213] DEKYBD

[0214] Specifies data entry keyboard feature. This feature implies PFKfeature; therefore, PFK is invalid if DEKYBD is specified. NOPFK impliesthe absence of PFK and DEKYBD features.

[0215] PFK

[0216] Specifies that the device has program function keys. NOPFKspecifies the absence of the PFK and DEKYBD features.

[0217] PEN

[0218] Specifies the selector light pen detect feature. NOPEN specifiesthe absence of the PEN feature.

[0219] 1|2|3|4|5|6|7|8|9|10

[0220] Specifies customer-defined features for the 3270P device type.

[0221] For 3270P devices, FEAT=allows grouping of devices with specialdevice characteristics. For example, FEAT=1 could group devices with amaximum of 80 print positions and no VFC, and FEAT=2 could group deviceswith 132 print positions and the VFC feature. FEAT=IGNORE should bespecified to group together devices with a minimum set of devicecapabilities. When WIDTH=is specified, FEAT=(1 . . . 10) must also bespecified. If FEAT=(1 . . . 10) is specified but WIDTH=is not specified,WIDTH=defaults to 120.

[0222] When IGNORE is specified, no other values should be coded in theFEAT=operand. When FEAT=IGNORE is not specified in the TERMINAL macroduring system definition, the MSG statement must specify IGNORE in theSOR=operand for the device format with the IGNORE specification. UnlessFEAT=IGNORE is used, FEAT=must specify exactly what was specified in theTERMINAL macro during IMS system definition. If it does not, the DFS057error message is issued. When FEAT=IGNORE or 1-10 is specified for 3270devices, the operands

[0223] PEN=, CARD=, and PFK=can still be specified. When TYPE=3270P andFEAT=IGNORE, MFS allows a line width of 120 characters.

[0224] CARD, PFK, DEKYBD, and PEN feature values are valid only for 3270displays. If the FEAT=operand is omitted, the default features are CARD,PFK, and PEN for 3270 displays; the default line width is 120 forTYPE=3270P.

[0225] 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10 are valid values only for 3270,3270P and 3270-An. For 3270 displays, the FEAT=specifications of 1 to 5can be used to group devices with specific features or hardware datastream dependencies.

[0226] Restriction: This keyword is optional and cannot be used with anyother feature specification for 3270 displays.

[0227] Feature operand values can be specified in any order, and onlythose values desired need be specified. The underlined values do nothave to be specified because they are defaults. Only one value in eachvertical list can be specified.

[0228] page:MFSPageType

[0229] PAGE attribute

[0230] Specifies output parameters as follows:

[0231] number

[0232] For printer devices, number defines the number of print lines ona printed page; for card devices, number defines the number of cards tobe punched per DPAGE or physical page (if pp parameter is used in theDFLD statements). This value is used for validity checking. The numberspecified must be greater than or equal to 1 and less than 256. Thedefault is 55.

[0233] DEFN

[0234] Specifies that lines/cards are to be printed/punched as definedby DFLD statements (no lines/cards are to be removed or added to theoutput page).

[0235] SPACE

[0236] Specifies that each output page contains the exact number oflines/cards specified in the number parameter.

[0237] FLOAT

[0238] Specifies that lines/cards with no data (all blank or NULL) afterformatting are to be deleted. For 3270P devices, some lines having nodata (that is, all blank or null) must not be deleted under thefollowing circumstances:

[0239] The line contains one or more set line density (SLDx=)specifications.

[0240] A field specified as having extended attributes spans more thanone line.

[0241] pen:String

[0242] PEN attribute

[0243] Defines an input field name to contain literal data when animmediate light pen detection of a field with a space or null designatorcharacter occurs. The literal data is defined on the DFLD statement withthe PEN=operand. (See PEN=operand on the DFLD statement.) This name canbe referred to by an MFLD statement and must not be used as the label ofa DFLD statement within this DEV definition. The PEN=operand is validonly for 3270 displays. If FEAT=NOPEN is specified, it is changed toPEN.

[0244] If an immediate detect occurs on a field defined with a space ornull designator character, and either another field has been selected ormodified or has the MOD attribute, or the PEN=operand is not defined forthe DFLD, a question mark (?) is inserted in the PEN=field name.

[0245] If no immediate detection occurs or the immediate detect occurson a field defined with an ampersand (&) designator character, thePEN=operand is padded with the fill specified in the MFLD statement.

[0246] pfk:MFSFunctionKeyType

[0247] PFK attribute

[0248] Defines an input field name to contain program function keyliteral or control function data (first subparameter) and, in positionalor keyword format, either the literal data to be placed in the specifiedfield, or the control function to be performed when the correspondingfunction key is entered (remaining subparameters).

[0249] The name of the first subparameter (the input field name thatwill contain the program function key literal or control function data)can be referred to by an MFLD statement and must not be used as thelabel of a DFLD statement within this DEV definition. The remainingsubparameters can be specified in positional or keyword format. If thesubparameters are in keyword format, the integer specified must be from1 to 36, inclusive, and not duplicated. Only one PFK=operand format(positional or keyword) can be specified on a DEV statement. Thisoperand is valid only for 3270 displays. At the time the actual formatblocks are created, each literal is padded on the right with blanks tothe length of the largest literal in the list. The maximum literallength is 256 bytes.

[0250] If the device supports the IMS copy function, then PFK12 invokesthe copy function and the definition of PFK12 in the DEV statement isignored; otherwise, the definition of PFK12 is honored.

[0251] If FEAT=NOPFK is specified, it is changed to PFK. The maximumnumber of user-defined PFKs is 36.

[0252] Control functions that can be specified are:

[0253] NEXTPP—PAGE ADVANCE

[0254] Specifies a request for the next physical page in the currentoutput message. If no output message is in progress, no explicitresponse is made.

[0255] NEXTMSG—MESSAGE ADVANCE

[0256] Specifies a request to dequeue the output message in progress (ifany) and to send the next output message in the queue (if any).

[0257] NEXTMSGP—MESSAGE ADVANCE PROTECT

[0258] Specifies a request to dequeue the output message in progress (ifany), and send the next output message or return an information messageindicating that no next message exists.

[0259] NEXTLP—NEXT LOGICAL PAGE

[0260] Specifies a request for the next logical page of the currentmessage.

[0261] ENDMPPI—END MULTIPLE PAGE INPUT

[0262] Specifies the end of a multiple physical page input message.

[0263] substitution:String

[0264] SUB attribute

[0265] Specifies the character used by MFS to replace any X‘3F’characters in the input data stream. No translation occurs if thisparameter is specified as X‘3F’ or this parameter is not specified, orthe input received bypasses MFS editing. The specified SUB charactershould not appear elsewhere in the data stream; therefore, it should benongraphic.

[0266] X‘hh’

[0267] Character whose hexadecimal representation is ‘hh’ replaces allX‘3F’ in the input data stream.

[0268] C‘c’

[0269] Character ‘c’ replaces all X‘3F’ in the input data stream.

[0270] type:String

[0271] TYPE attribute

[0272] Specifies the device type and model number of a device using thisformat description. The 3284-3 printer attached to a 3275 is supportedonly as TYPE=3270P. The model number specified when defining a formatfor a 3284-3 is the model number of the associated 3275.

[0273] TYPE=3270-An specifies a symbolic name for 3270 and SLU 2displays with the screen size defined during IMS system definition,feature numbers n=1-15. This specification causes the MFS Languageutility to read the MFS device characteristics table (DFSUDT0x) toextract the screen size.

[0274] width:int

[0275] WIDTH attribute

[0276] Specifies the maximum line width for this DEV type as one of:

[0277] Number of print positions per line of input or output data

[0278] Number of punch positions per card of input or output data

[0279] Card width for card reader input data

[0280] The default is 120 for 3270P output. Line width is specifiedrelative to column 1, regardless of whether a left margin value isspecified in the HTAB=keyword. The width specified must be greater thanor equal to 1.

[0281] For 3270P devices, if WIDTH is specified, then FEAT=(1 . . . 10)must also be specified. If FEAT=(1 . . . 10) is specified, and WIDTH=isnot specified, WIDTH=defaults to 120.

[0282] MFSMessageDescriptor

[0283] MSG statement

[0284] The MSG statement initiates and names a message input or outputdefinition.

[0285] Unsupported attributes:

[0286] All attributes are supported

[0287] Derived from MFSStatement

[0288] Private Attributes:

[0289] fill:String

[0290] FILL attribute

[0291] Specifies a fill character for output device fields. This operandis valid only if TYPE=OUTPUT. The default is C‘’ The fill specificationis ignored unless FILL=NONE is specified on the DPAGE statement in theFMT definition. For 3270 output when EGCS fields are present, onlyFILL=PT or FILL=NULL should be specified. A FILL=PT erases an outputfield (either a 1- or 2-byte field) only when data is sent to the field,and thus does not erase the DFLD if the application program messageomits the MFLD.

[0292] C‘c’

[0293] Character ‘c’ is used to fill device fields. For 3270 displaydevices, any specification with a value less than X‘3F’ is changed toX‘00’ for control characters or to X‘40’ for other nongraphiccharacters. For all other devices, any FILL=C‘c’ specification with avalue less than X‘3F’ is ignored and defaulted to X‘3F’ (which isequivalent to a specification of FILL=NULL).

[0294] NULL

[0295] Specifies that fields are not to be filled.

[0296] PT

[0297] Is identical to NULL except for 3270 display. For 3270 display,PT specifies that output fields that do not fill the device field (DFLD)are followed by a program tab character to erase data previously in thefield.

[0298] IgnoreSource:Boolean

[0299] SOR attribute

[0300] Specifies the source name of the FMT statement which, with theDEV statement, defines the terminal or remote program data fieldsprocessed by this message descriptor. Specifying IGNORE for TYPE=OUTPUTcauses MFS to use data fields specified for the device whoseFEAT=operand specifies IGNORE in the device format definition. ForTYPE=INPUT, IGNORE should be specified only if the corresponding messageoutput descriptor specified IGNORE. If you use SOR=IGNORE, you mustspecify IGNORE on both the message input descriptor and the messageoutput descriptor.

[0301] option:int

[0302] OPT attribute

[0303] Specifies the message formatting option used by MFS to editmessages. The default is 1.

[0304] paging:boolean

[0305] PAGE attribute

[0306] Specifies whether (YES) or not (NO) operator logical paging(forward and backward paging) is to be provided for messages editedusing this control block. This operand is valid only if TYPE=OUTPUT. Thedefault is NO, which means that only forward paging of physical pages isprovided.

[0307] type:MFSDescriptorType

[0308] TYPE attribute

[0309] Defines this definition as a message INPUT or OUTPUT controlblock. The default is INPUT.

[0310] MFSLogicalPage

[0311] LPAGE statement

[0312] The optional LPAGE statement defines a group of segmentscomprising a logical page. It is implied if not present.

[0313] Unsupported attributes:

[0314] All attributes are supported

[0315] Derived from MFSStatement

[0316] Private Attributes:

[0317] condition:MFSConditionType

[0318] COND attribute

[0319] Describes a conditional test that, if successful, specifies thatthe segment and field definitions following this LPAGE are to be usedfor output editing of this logical page. The specified portion of thefirst segment of a logical page is examined to determine if it isgreater than (>), less than (<), greater than or equal to (°), less thanor equal to (°), equal to (=), or not equal to (ne) the specifiedliteral value to determine if this LPAGE is to be used for editing.COND=is not required for the last LPAGE statement in the MSG definition.

[0320] The area examined can be defined by a field name (mfldname), anoffset in a field (mfldname(pp) where pp is the offset in the namedfield), or an offset in the segment (segoffset). If the mfldname(pp)form is used, pp must be greater than or equal to 1. The length of thecompare is the length of the specified literal. If OPT=3 is specified onthe previous MSG statement, the area to be examined must be within onefield as defined on an MFLD statement.

[0321] If segoffset is used, it is relative to zero, and thespecification of that offset must allow for LLZZ of the segment (thatis, the first data byte is at offset 4).

[0322] If pp is used, the offset is relative to 1 with respect to thenamed field (that is, the first byte of data in the field is at offset1, not zero).

[0323] If the mfldname specified is defined with ATTR=YES, the pp offsetmust be used. The minimum offset specified must be 3. That is, the firstbyte of data in the field is at offset 3, following the two bytes ofattributes.

[0324] If ATTR=nn is specified, the minimum offset must be one plustwice nn. Thus, if ATTR=2 is specified, pp must be at least 5, and, ifATTR=(YES,2) is specified, pp must be at least 7.

[0325] If the conditional tests for all LPAGEs fail, the last LPAGE inthis MSG definition is used for editing. If LPAGE selection is to bespecified using the command data field, that is, /FORMAT modname . . .(data), the MFLD specified in the LPAGE COND=mfldname parameter shouldbe within the first 8 bytes of the associated LPAGEs of the MOD.

[0326] promptValue:String

[0327] MFSSegment

[0328] SEG statement

[0329] The SEG statement delineates message segments and is requiredonly if multisegment message processing is required by the applicationprogram. Output message segments cannot exceed your specified queuebuffer length. Only one segment should be defined for TYPE=INPUT MSGswhen the input message destination is defined as a single segmentcommand or transaction. If more than one segment is defined, and thedefinition is used to input a single segment command or transaction,care must be used to ensure that your input produces only one segmentafter editing. It is implied if not present.

[0330] Unsupported attributes:

[0331] All attributes are supported

[0332] Derived from MFSStatement

[0333] Private Attributes:

[0334] exit:MFSExitType

[0335] EXIT attribute

[0336] Describes the segment edit exit routine interface for thismessage segment. exitnum is the exit routine number and exitvect is avalue to be passed to the exit routine when it is invoked for thissegment, exitnum can range from 0 to 127. exitvect can range from 0 to255. The SEG exit is invoked when processing completes for the inputsegment.

[0337] graphic:boolean

[0338] GRAPHIC attribute

[0339] Specifies for MSG TYPE=INPUT whether (YES) or not (NO) IMS shouldperform upper case translation on this segment if the destinationdefinition requests it (see the EDIT=parameter of the TRANSACT or NAMEmacro). The default is YES. If input segment data is in nongraphicformat (packed decimal, EGCS, binary, and so forth), GRAPHIC=NO shouldbe specified. When GRAPHIC=NO is specified, FILL=NULL is invalid forMFLDs within this segment.

[0340] The list below shows the translation that occurs when GRAPHIC=YESis specified and the input message destination is defined as requestingupper case translation:

[0341] Before Translation After Translation

[0342] a through z

[0343] A through Z

[0344] X‘81’ through X‘89’

[0345] X‘C1’ through X‘C9’

[0346] X‘91’ through X‘99’

[0347] X‘D1’ through X‘D9’

[0348] X‘A2’ through X‘A9’

[0349] X‘E2’ through X‘E9’

[0350] If FILL=NULL is specified for any MFLD in a segment defined asGRAPHIC=YES, the hexadecimal character X‘3F’ is compressed out of thesegment. If GRAPHIC=NO and FILL=NULL are specified in the SEG statement,any X‘3F’ in the non-graphic data stream is compressed out of thesegment and undesirable results might be produced. Non-graphic datashould be sent on output as fixed length output fields and the use ofFILL=NULL is not recommended in this case.

[0351] For MSG TYPE=OUTPUT, the GRAPHIC=keyword applies only for DPM. Itspecifies whether (YES) or not (NO) nongraphic control characters (X‘00’to X‘3F’) in the data from the IMS application program are to bereplaced by blanks. The default value is YES. If NO is specified, MFSallows any bit string received from an IMS application program to flowunmodified through MFS to the remote program.

[0352] Restriction: When GRAPHIC=NO is specified, IMS applicationprograms using Options 1 and 2 cannot omit segments in the middle of anLPAGE, or truncate or omit fields in the segment using the nullcharacter (X‘3F’).

[0353] MFSMessageField

[0354] MFLD statement

[0355] The MFLD statement defines a message field as it will bepresented to an application program as part of a message output segment.At least one MFLD statement must be specified for each MSG definition.

[0356] Unsupported attributes:

[0357] All attributes are supported

[0358] Derived from MFSStatement

[0359] Private Attributes:

[0360] attributes:boolean

[0361] ATTR attribute

[0362] Specifies whether (YES) or not (NO) the application program canmodify the 3270 attributes and the extended attributes (nn).

[0363] If YES, 2 bytes must be reserved for the 3270 attribute data tobe filled in by the application program on output and to be initializedto blanks on input. These 2 bytes must be included in theLTH=specification.

[0364] The value supplied for nn is the number of extended attributesthat can be dynamically modified. The value of nn can be a number from 1to 6. An invalid specification will default to 1. Two additional bytesper attribute must be reserved for the extended attribute data to befilled in by the application program on output and to be initialized toblanks on input. These attribute bytes must be included in the MFLDLTH=specification.

[0365] Example: Shown below are valid specifications for ATTR=and thenumber of bytes that must be reserved for each different specification:

[0366] MFLD,ATTR=(YES,nn) 2+(2×nn)

[0367] MFLD ,ATTR=(NO,nn) 2×nn

[0368] MFLD ,ATTR=(nn) 2×nn

[0369] MFLD ,ATTR=YES 2

[0370] MFLD ,ATTR=NO 0

[0371] ATTR=YES and nn are invalid if a literal value has been specifiedthrough the positional parameter in an output message.

[0372] The attributes in a field sent to another IMS ISC subsystem aretreated as input data by MFS regardless of any ATTR=specifications inthe format of the receiving subsystem. For example, a message field(MFLD) defined as ATTR=(YES,1),LTH=5 would contain the following:

[0373] 00A0C2F1C8C5D3D3D6

[0374] If the MFLD in the receiving subsystem is defined as LTH=9 andwithout ATTR=, the application program receives:

[0375] 00A0C2F1C8C5D3D3D6

[0376] If the MFLD in the receiving subsystem is defined as LTH=13 andATTR=(YES,1), the application program receives:

[0377] 4040404000A0C2F1C8C5D3D3D6

[0378] If the MFLD in the receiving subsystem is defined as LTH=5 andATTR=(YES,1), the application program receives:

[0379] 4040404000A0C2F1C8

[0380] The input SEG statement should be specified as GRAPHIC=NO toprevent translation of the attribute data to uppercase.

[0381] exit:MFSExitType

[0382] EXIT attribute

[0383] Describes the field edit exit routine interface for this messagefield. The exit routine number is specified in exitnum, and exitvect isa value to be passed to the exit routine when it is invoked for thisfield. The value of exitnum can range from 0 to 127. The value ofexitvect can range from 0 to 255. The address of the field as it existsafter MFS editing, (but before NULL compression for option 1 and 2), ispassed to the edit exit routine, along with the vector defined for thefield. (If NOFLDEXIT is specified for a DPM device, the exit routinewill not be invoked.) The exit routine can return a code with a valuefrom 0 to 255. MFS maintains the highest such code returned for eachsegment for use by the segment edit routine. EXIT=is invalid if‘literal’ is specified on the same MFLD statement.

[0384] extendedAttributes:int

[0385] ATTR attribute

[0386] Specifies whether (YES) or not (NO) the application program canmodify the 3270 attributes and the extended attributes (nn).

[0387] If YES, 2 bytes must be reserved for the 3270 attribute data tobe filled in by the application program on output and to be initializedto blanks on input. These 2 bytes must be included in theLTH=specification.

[0388] The value supplied for nn is the number of extended attributesthat can be dynamically modified. The value of nn can be a number from 1to 6. An invalid specification will default to 1. Two additional bytesper attribute must be reserved for the extended attribute data to befilled in by the application program on output and to be initialized toblanks on input. These attribute bytes must be included in the MFLDLTH=specification.

[0389] Example: Shown below are valid specifications for ATTR=and thenumber of bytes that must be reserved for each different specification:

[0390] MFLD ,ATTR=(YES,nn) 2+(2×nn)

[0391] MFLD,ATTR=(NO,nn) 2×nn

[0392] MFLD,ATTR=(nn) 2×nn

[0393] MFLD ,ATTR=YES 2

[0394] MFLD ,ATTR=NO 0

[0395] ATTR=YES and nn are invalid if a literal value has been specifiedthrough the positional parameter in an output message.

[0396] The attributes in a field sent to another IMS ISC subsystem aretreated as input data by MFS regardless of any ATTR=specifications inthe format of the receiving subsystem. For example, a message field(MFLD) defined as ATTR=(YES,1),LTH=5 would contain the following:

[0397] 00A0C2F1C8C5D3D3D6

[0398] If the MFLD in the receiving subsystem is defined as LTH=9 andwithout ATTR=, the application program receives:

[0399] 00A0C2F1C8C5D3D3D6

[0400] If the MFLD in the receiving subsystem is defined as LTH=13 andATTR=(YES,1), the application program receives:

[0401] 4040404000A0C2F1C8C5D3D3D6

[0402] If the MFLD in the receiving subsystem is defined as LTH=5 andATTR=(YES,1), the application program receives:

[0403] 4040404000A0C2F1C8

[0404] The input SEG statement should be specified as GRAPHIC=NO toprevent translation of the attribute data to uppercase.

[0405] fill:String

[0406] FILL attribute

[0407] Specifies a character to be used to pad this field when thelength of the data received from the device is less than the length ofthis field. This character is also used to pad when no data is receivedfor this field (except when MSG statement specifies option 3.) Thisoperand is only valid if TYPE=INPUT. The default is X‘40’.

[0408] X‘hh’

[0409] Character whose hexadecimal representation is hh is used to fillfields.

[0410] FILL=X‘3F’ is the same as FILL=NULL.

[0411] C‘c’

[0412] Character c is used to fill fields.

[0413] NULL

[0414] Causes compression of the message segment to the left by theamount of missing data in the field.

[0415] justify:MFSjustifyType

[0416] JUST attribute

[0417] Specifies that the data field is to be left-justified (L) orright-justified (R) and right- or left- truncated as required, dependingupon the amount of data expected or presented by the device formatcontrol block. The default is L.

[0418] length:MFSLengthType

[0419] LTH attribute

[0420] Can be omitted if a literal is specified in the positionaloperand (TYPE=INPUT), in which case, length specified for literal isused. If LTH=is specified for a literal field, the specified literal iseither truncated or padded with blanks to the specified length. If theMFLD statement appears between a DO and an ENDDO statement, a lengthvalue is printed on the generated MFLD statement, regardless of whetherLTH=is specified in the MFLD source statement.

[0421] value:String

[0422] value attribute

[0423] This corresponds to the ‘literal’ field in the followingdescription.

[0424] The device field name is specified via the ‘deviceFields’relationship. Specifies the device field name (defined via the DEV orDFLD statement) from which input data is extracted or into which outputdata is placed. If this parameter is omitted when defining a messageoutput control block, the data supplied by the application program isnot displayed on the output device. If the repetitive generationfunction of MFS is used (DO and ENDDO statements), dfldname should berestricted to 6 characters maximum length. When each repetition of thestatement is generated, a 2-character sequence number (01 to 99) isappended to dfldname. If the dfldname specified here is greater than 6bytes and repetitive generation is used, dfldname is truncated at 6characters and a 2-character sequence number is appended to form an8-character name. No error message is provided if this occurs. Thisparameter can be specified in one of the following formats:

[0425] dfldname

[0426] Identifies the device field name from which input data isextracted or into which output data is placed.

[0427] ‘literal’

[0428] Can be specified if a literal value is to be inserted in an inputmessage.

[0429] (dfldname, ‘literal’)

[0430] If TYPE=OUTPUT, this describes the literal data to be placed inthe named DFLD. When this form is specified, space for the literal mustnot be allocated in the output message segment supplied by theapplication program.

[0431] If TYPE=INPUT, this describes the literal data to be placed inthe message field when no data for this field is received from thedevice. If this dfldname is used in the PFK parameter of a DEVstatement, this literal is always replaced by the PF key literal orcontrol function. However, when this dfldname is specified in the PFKparameter, but the PF key is not used, the literal specified in the MFLDstatement is moved into the message field. When physical paging is used,the literal is inserted in the field but is not processed until afterthe last physical page of the logical page has been displayed.

[0432] In both cases, if the LTH=operand is specified, the length of theliteral is truncated or padded as necessary to the length of theLTH=specification. If the length of the specified literal is less thanthe defined field length, the literal is padded with blanks ifTYPE=OUTPUT and with the specified fill character (FILL=) if TYPE=INPUT.If no fill character is specified for input, the literal is padded withblanks (the default). The length of the literal value cannot exceed 256bytes.

[0433] (dfldname,system-literal)

[0434] Specifies a name from a list of system literals. A system literalfunctions like a normal literal except that the literal value is createdduring formatting prior to transmission to the device. The LTH=, ATTR=,and JUST=operands cannot be specified. When this form is specified,space for the literal must not be allocated in the output messagesegment supplied by the application program.

[0435] (,SCA)

[0436] Defines this output field as the system control area which is notdisplayed on the output device. There can be only one such field in alogical page (LPAGE) and it must be in the first message segment of thatpage. If no logical pages are defined, only one SCA field can be definedand it must be in the first segment of the output message. Thisspecification is valid only if TYPE=OUTPUT was specified on the previousMSG statement.

[0437] MFSDevicePage

[0438] DPAGE statement

[0439] The DPAGE statement defines a logical page of a device format.This statement can be omitted if none of the message descriptorsreferring to this device format (FMT) contains LPAGE statements and ifno specific device option is required. It is implied if not present.

[0440] Unsupported attributes:

[0441] ACTVPID

[0442] COND

[0443] OFTAB

[0444] ORIGIN

[0445] PD

[0446] SELECT

[0447] Derived from MFSStatement

[0448] Private Attributes:

[0449] cursor:MFSCursorType

[0450] CURSOR attribute

[0451] Specifies the position of the cursor on a physical page. Multiplecursor positions may be required if a logical page or message consistsof multiple physical pages. The value lll specifies line number, cccspecifies column; both lll and ccc must be greater than or equal to 1.The cursor position must either be on a defined field or defaulted. Thedefault lll,ccc value for 3270 displays is 1,2. For Finance displaycomponents, if no cursor position is specified, MFS will not positionthe cursor—the cursor is normally placed at the end of the output dataon the device. For Finance display components, all cursor positioning isabsolute, regardless of the ORIGIN=parameter specified.

[0452] The dfld parameter provides a method for supplying theapplication program with cursor information on input and allowing theapplication program to specify cursor position on output.

[0453] Recommendation: Use the cursor attribute facility (specifyATTR=YES in the MFLD statement) for output cursor positioning.

[0454] The dfld parameter specifies the name of a field containing thecursor position. This name may be referenced by an MFLD statement andmust not be used as the label of a DFLD statement in this DEVdefinition. The format of this field is two binary halfwords containingline and column number, respectively. When this field is referred to bya message input descriptor, it will contain the cursor position atmessage entry. If referred to by a message output descriptor, theapplication program places the desired cursor position into this fieldas two binary halfwords containing line and column, respectively. Binaryzeros in the named field cause the specified lll,ccc to be used forcursor positioning during output. During input, binary zeros in thisfield indicate that the cursor position is not defined. The input MFLDreferring to this dfld should be defined within a segment withGRAPHIC=NO specified or should use EXIT=(0,2) to convert the binarynumbers to decimal.

[0455] fill:String

[0456] FILL attribute

[0457] Specifies a fill character for output device fields. Defaultvalue for all device types except the 3270 display is X‘40’; default forthe 3270 display is PT. For 3270 output when EGCS fields are present,only FILL=PT or FILL=NULL should be specified. A FILL=PT erases anoutput field (either a 1- or 2-byte field) only when data is sent to thefield, and thus does not erase the DFLD if the application programmessage omits the MFLD.

[0458] NONE

[0459] Must be specified if the fill character from the message outputdescriptor is to be used to fill the device fields.

[0460] X‘hh’

[0461] Character whose hexadecimal representation is ‘hh’ will be usedto fill the device fields.

[0462] C‘c’

[0463] Character ‘c’ will be used to fill the device fields.

[0464] NULL

[0465] Specifies that fields are not to be filled. For devices otherthan the 3270 display, ‘compacted lines’ are produced when message datadoes not fill the device fields.

[0466] PT

[0467] Specifies that output fields that do not fill the device field(DFLD) are followed by a program tab character to erase data previouslyin the field; otherwise, this operation is identical to FILL=NULL.

[0468] For 3270 display devices, any specification with a value lessthan X‘3F’ is changed to X‘00’ for control characters or to X‘40’ forother nongraphic characters.

[0469] multiplePages:boolean

[0470] MULT attribute

[0471] Specifies that multiple physical page input messages will beallowed for this DPAGE.

[0472] MFSDeviceField

[0473] DFLD statement

[0474] The DFLD statement defines a field within a device format whichis read from or written to a terminal or remote program. Only thoseareas which are of interest to the IMS or remote application programshould be defined. Null space in the format does not need to be defined.

[0475] Unsupported attributes:

[0476] SLD

[0477] Derived from MFSStatement

[0478] Private Attributes:

[0479] attributes:MFSAttributeType

[0480] ATTR attribute

[0481] extendedAttributes:MFSExtendedAttributeType

[0482] EATTR attribute

[0483] length:int

[0484] LTH attribute

[0485] Specifies the length of the field. This operand should be omittedif ‘literal’ is specified in the positional parameter, in which case thelength of literal is used as the field length. Unpredictable outputformatting can occur if this operand is used in conjunction with a‘literal’ and the two lengths are different. The specified LTH=cannotexceed the physical page size of the device.

[0486] The maximum allowable length for all devices except 3270, 3604display, and DPM with RCDCT=NOSPAN is 8000 characters. For 3270displays, the maximum length is one less than screen size. For example,for a 480-character display, the maximum length is 479 characters. Alength of 0 must not be specified. If SCA and LTH=are both specified,LTH must be 2.

[0487] POS=and LTH=do not include the attribute character positionreserved for a 3270 display device or a DFLD with ATTR=YES specified.The inclusion of this byte in the design of display/printer formats isnecessary because it occupies the screen/printed page position precedingeach displayed/printed field even though it is not accessible by anapplication program.

[0488] When defining DFLDs for 3270 printers, a hardware ATTRIBUTEcharacter is not used. Therefore, fields must be defined with ajuxtaposition that does not allow for the attribute character unlessATTR=YES is specified. However, for printers defined as 3270P the lastcolumn of a print line (based on FEAT=, WIDTH=, or the device defaultwidth) cannot be used. The last column of the line is reserved forcarriage control operations performed by IMS. Thus, if the print linespecifies 120 (FEAT=120) and the DFLD specifies POS=(1,1),LTH=120 then119 characters are printed on line 1 and one character on line 2.

[0489] Detectable fields (DET or IDET) must include four positions inPOS and LTH for a 1-byte detection designator character and 3 padcharacters, unless the detectable field is the last field on a displayline, in which case only one position for the detection designatorcharacter is required. The detection designator character must precedefield data, and pad characters (if required) follow field data.Detection designator and required pad characters must be supplied by theapplication program or MFLD literal with the field data. Pad characterscan also be required in the preceding field on the device.

[0490] pen:String

[0491] PEN attribute

[0492] Specifies a literal to be selected or an operator controlfunction to be performed when this field is detected. If (1)‘literal’ isspecified, (2) the field is defined as immediately detectable(ATTR=operand), and (3) contains the null or space designator character,the specified literal is placed in the field referred to by the PENoperand of the preceding DEV statement when the field is detected (if noother device fields are modified). If another field on the device ismodified, a question mark (?) is provided instead of the literal.Literal length must not exceed 256 bytes.

[0493] If (1) a control function is specified, (2) the field is definedas immediately detectable (ATTR=operand), and (3) contains the null orspace designator character, the specified control function is performedwhen the field is detected and no other device fields are modified. Ifanother field on the device is modified, a question mark (?) is providedand the function is not performed. Control functions that can bespecified are:

[0494] NEXTPP—PAGE ADVANCE

[0495] Specifies a request for the next physical page in the currentoutput message. If no output message is in progress, no explicitresponse is made.

[0496] NEXTMSG—MESSAGE ADVANCE

[0497] specifies a request to dequeue the output message in progress (ifany) and to send the next output message in the queue (if any).

[0498] NEXTMSGP—MESSAGE ADVANCE PROTECT

[0499] Specifies a request to dequeue the output message in progress (ifany), and send the next output message or return an information messageindicating that no next message exists.

[0500] NEXTLP—NEXT LOGICAL PAGE

[0501] Specifies a request for the next logical page of the currentmessage.

[0502] ENDMPPI—END MULTIPLE PAGE INPUT

[0503] Specifies the end of a multiple physical page input message.

[0504] ENDMPPI is valid only if data has been received and will notterminate multiple page input (MPPI) in the absence of data entry.

[0505] position:MFSPositionType

[0506] POS attribute

[0507] Defines the first data position of this field in terms of line(lll), column (ccc), and physical page (pp) of the display format. If ppis omitted, 1 is assumed.

[0508] For DEV TYPE=3270, 3270-An, or 3270P

[0509] lll,ccc,pp

[0510] Specifies the line, column, and optionally, the physical pagenumber for an output field. lll, ccc, and pp must be greater than orequal to 1.

[0511] For 3270 displays, POS=(1,1) must not be specified. Fields mustnot be defined such that they wrap from the bottom to the top.

[0512] Restriction: On some models of 3270s, the display screen cannotbe copied when a field starting on line 1, column 2, has both alphabeticand protect attributes.

[0513] value:String

[0514] MFSTable

[0515] TABLE statement

[0516] The TABLE statement initiates and names an operator control tablethat can be referred to by the OPCTL keyword of the DFLD statement. TheTABLE statement, and the IF and TABLEEND statements that follow, must beoutside of a MSG or FMT definition.

[0517] Unsupported attributes:

[0518] All attributes are supported

[0519] Derived from MFSStatement

[0520] MFSDeviceDivision

[0521] DIV statement

[0522] The DIV statement defines device formats within a DIF or DOF. Theformats are identified as input, output, or both input and output, andcan consist of multiple physical pages. Only one DIV statement per DEVis allowed.

[0523] Unsupported attributes:

[0524] RCDCTL

[0525] HDRCTL

[0526] OPTIONS

[0527] OFTAB

[0528] DPN

[0529] PRN

[0530] RDPN

[0531] RPRN

[0532] Derived from MFSStatement

[0533] Private Attributes:

[0534] type:MFSDescriptorType

[0535] TYPE attribute

[0536] Describes an input only format (INPUT), an output only format(OUTPUT), or both (INOUT).

[0537] If DIV TYPE=OUTPUT or TYPE=INPUT is specified, certain DEVstatement keywords are applicable.

[0538] compression:MFSCompressionType

[0539] COMPR attribute

[0540] Requests MFS to remove trailing blanks from short fields,fixed-length fields, or all fields presented by the application program.

[0541] MFSIfCondition

[0542] IF statement

[0543] The IF statement defines an entry in the table named by theprevious TABLE statement. Each IF statement defines a conditionaloperation and an associated control or branching function to beperformed if the condition is true.

[0544] Unsupported attributes:

[0545] All attributes are supported

[0546] Derived from MFSStatement

[0547] Private Attributes:

[0548] condition:MFSConditionType

[0549] condition attribute

[0550] Condition has the following format:

[0551] IF (DATA|LENGTH) (=,<,>,

,°,°) (literal|data-length) function

[0552] DATA

[0553] Specifies that the conditional operation is to be performedagainst the data received from the device for the field.

[0554] LENGTH

[0555] Specifies that the conditional operation is testing the number ofcharacters entered for the field. The size limit for this field is thesame as for DFLDs (see “DFLD Statement” in topic 2.5.1.5.8). =,<,>

, °, °

[0556] Specify the conditional relationship that must be true to invokethe specified control function.

[0557] ‘literal’

[0558] Is a literal string to which input data is to be compared. Thecompare is done before the input is translated to upper case.If‘literal’ is specified, DATA must be specified in the first operand.If the input data length is not equal to the literal string length, thecompare is performed with the smaller length, unless the conditionalrelationship is

and the data length is zero, in which case the control function isperformed. If the input is in lowercase, the ALPHA statement should beused and the literal coded in lowercase.

[0559] data-length

[0560] Specifies an integer value to which the number of characters ofinput data for the field is compared.

[0561] NOFUNC

[0562] Specifies that conditional function testing is to be terminated.

[0563] NEXTPP—PAGE ADVANCE

[0564] Specifies a request for the next physical page in the currentoutput message. If no output message is in progress, no explicitresponse is made.

[0565] NEXTMSG—MESSAGE ADVANCE

[0566] Specifies a request to dequeue the output message in progress (ifany) and to send the next output message in the queue (if any).

[0567] NEXTMSGP—MESSAGE ADVANCE PROTECT

[0568] Specifies a request to dequeue the output message in progress (ifany), and either send the next output message or return an informationmessage indicating that no next message exists.

[0569] NEXTLP—NEXT LOGICAL PAGE

[0570] Specifies a request for the next logical page of the currentmessage.

[0571] PAGEREQ—LOGICAL PAGE REQUEST

[0572] Specifies that the second through last characters of input dataare to be considered as a logical page request.

[0573] ENDMPPI—END MULTIPLE PAGE INPUT

[0574] Specifies the end of multiple physical page input (this input isthe last for the message being created).

[0575] action:String

[0576] MFSPassword

[0577] PASSWORD statement

[0578] The PASSWORD statement identifies one or more fields to be usedas an IMS password. When used, the PASSWORD statement and its associatedMFLDs must precede the first SEG statement in an input LPAGE or MSGdefinition. Up to 8 MFLD statements can be specified after the PASSWORDstatement but the total password length must not exceed 8 characters.The fill character must be X‘40’. For option 1 and 2 messages, the first8 characters of data after editing are used for the IMS password. Foroption 3 messages, the data content of the first field after editing isused for the IMS password.

[0579] A password for 3270 input can also be defined in a DFLDstatement. If both password methods are used, the password specified inthe MSG definition is used.

[0580] Unsupported attributes:

[0581] All attributes are supported

[0582] Derived from MFSStatement

[0583] MFSDeviceDescriptor

[0584] FMT statement The FMT statement initiates and names a formatdefinition that includes one or more device formats differing only inthe device type and features specified in the DEV statement. Each deviceformat included in the format definition specifies the layout for datasent to or received from a device or a remote program.

[0585] Unsupported attributes:

[0586] All attributes are supported

[0587] Derived from MFSStatement

[0588] MFSFunctionKeyType

[0589] Private Attributes:

[0590] filename:String

[0591] MFSFunctionKeyValueType

[0592] Private Attributes:

[0593] index:int

[0594] function:String

[0595] MFSFormatLibrary

[0596] This class is designed to duplicate the effects of a FORMATLIB.In other words, it acts as a central point around which MFS sourcesfiles are grouped.

[0597] This class was introduced to address the problem of MSG and LPAGEstatements referring to MSG statements in other source files. Rather toforce the user to parse every source file in a given formatlib at once,this class was added to act as a container to MSG pointers. Please seeMFSMessagePointer documentation for more information.

[0598] Private Attributes:

[0599] name:String

[0600] MFSMessagePointer

[0601] This class is designed to act as a placeholder for MSGstatements. Rather than point to actual MSG statements from the NXTattribute (nextMessage relationship), MSG and LPAGE statements willpoint to an instance of this class.

[0602] A new instance of this class will be created when a MSG or LPAGEstatement points to a MSG statement that is not represented in thisparticular FORMATLIB. A new instance will also be created when an MSGstatement is parsed, if that statement is not already represented here.

[0603] Private Attributes:

[0604] name:String

[0605] TOTALS:

[0606] 1 Logical Packages

[0607] 16 Classes

[0608] LOGICAL PACKAGE STRUCTURE

[0609] Logical View mfs

[0610] While the invention has been described with respect to certainpreferred embodiments and exemplifications, it is not intended to limitthe scope of the invention thereby, but solely by the claims appendedhereto.

We claim:
 1. A method of processing an application request on an enduser application and an application server including a transactionmessage formatter comprising the steps of: a) initiating the applicationrequest on the end user application in a first language with a firstapplication program; b) transmitting the application request to theserver and converting the application request from the first language ofthe first end user application to a form for the transaction messageformatter running on the application server; c) processing saidapplication request on the application server; d) transmitting aresponse to the application request from the application server to theend user application, and converting the response to the applicationrequest from the transaction message formatter running on theapplication server to the first language of the first end userapplication; and e) wherein the end user application and the applicationserver have at least one connector therebetween, and the steps of (i)converting the application request from the first language of the firstend user application as a source language to the language running on theapplication server as a target language, and (ii) converting a responseto the application request from the language running on the applicationserver as a source language to the first language of the first end userapplication as a target language, each comprise the steps of: 1)invoking connector metamodels of respective source language and targettransaction message formatter; 2) populating the connector metamodelswith metamodel data of each of the respective source language and targettransaction message formatter, the metamodel data of the targettransaction message formatter including a message descriptor, logicalpage, password, segment, message field, device descriptor, device type,device division, device page and device field; and 3) converting thesource language to the transaction message formatter.
 2. The method ofclaim 1 wherein the end user application is a web browser.
 3. The methodof claim 2 wherein the end user application is connected to theapplication server through a web server, and the web server comprises aconnector.
 4. The method of claim 1 wherein the metamodel comprisesinvocation metamodel data, application domain interface metamodel data,transaction message metamodel data, and type descriptor metamodel data.5. A transaction processing system comprising a client, a server, and atleast one connector therebetween, a) the client having an end userapplication, and being controlled and configured to initiate anapplication request with the server in a first language with a firstapplication program and to transmit the application request to theserver; b) the connector being configured and controlled to receive theapplication request from the client, convert the application requestfrom the first language of the first end user application running on theclient to a language and a transaction message formatter running on theserver; c) the server being configured and controlled to receive theconverted application request from the connector and processing the saidapplication request in a second language with a second applicationprogram residing on the server, and to thereafter transmit a response tothe application request through the connector back to the firstapplication program on the client; d) the connector being configured andcontrolled to receive a response to the application request from theserver, to convert a response to the application request from thelanguage running on the application server to the first language of thefirst application program running on the client; and e) whereinconnector between the client and the server is configured and controlledto (i) convert the application request from the first language of theclient application on the client as a source language to the languagerunning on the application server as a target language, and (ii) convertthe response to the application request from the language running on theapplication server as a source language to the first language of theclient application running on the client as a target language, each by amethod comprising the steps of: 1) retrieving connector metamodels ofrespective source and target languages and target transaction messageformatter from a metamodel data repository, said transaction messageformatter metadata including a message descriptor, logical page,password, segment, message field, device descriptor, device type, devicedivision, device page and device field; 2) populating the connectormetamodels with metamodel data from the metamodel data repository foreach of the respective source and target languages; and 3) invoking theretrieved, populated connector metamodels and converting the sourcelanguage to the target language.
 6. The system of claim 5 wherein theend user application is a web browser.
 7. The system of claim 6 whereinthe end user application is connected to the application server througha web server, and the web server comprises an connector.
 8. Atransaction processing system configured and controlled to interact witha client application, and comprising a server, and at least oneconnector between the server and the client application, where theclient has an end user application, and is controlled and configured toinitiate an application request with the server in a first language witha first application program and to transmit the application request tothe server, wherein: a) the connector being configured and controlled toreceive an application request from the client, convert the applicationrequest from the first language of the first end user applicationrunning on the client to a language running on the server; b) the serverbeing configured and controlled to receive the converted applicationrequest from the connector and process the said application request in asecond language with a second application program and a targettransaction message formatter residing on the server, and to thereaftertransmit a response to the application request through the connectorback to the first application program on the client; c) the connectorbeing configured and controlled to receive the application request fromthe server, to convert a response to the application request from thelanguage running on the application server to the first language of thefirst application program running on the client; and d) whereinconnector between the client and the server is configured and controlledto (i) convert the application request from the first language of theclient application on the client as a source language to the languagerunning on the application server as a target language, and (ii) convertthe response to the application request from the language running on theapplication server as a source language to the first language of theclient application running on the client as a target language, each by amethod comprising the steps of: 1) retrieving connector metamodel dataof respective source and target languages from a metamodel datarepository; 2) populating the connector metamodels with metamodel dataof each of the respective source and target languages and targettransaction message formatter, from the metamodel data repository, saidtarget transaction message formatter metadata including a messagedescriptor, logical page, password, segment, message field, devicedescriptor, device type, device division, device page and device field;and invoking the retrieved, populated connector metamodels; and 3)converting the source language to the target language.
 9. The system ofclaim 8 wherein the end user application is a web browser.
 10. Thesystem of claim 9 wherein the end user application is connected to theapplication server through a web server, and the web server comprises anconnector.
 11. A program product comprising a storage medium havinginvocation metamodel data, application domain interface metamodel data,language metamodel data, and transaction message formatter metamodeldata, said transaction message formatter metamodel data including amessage descriptor, logical page, password, segment, message field,device descriptor, device type, device division, device page and devicefield; and computer instructions for building a metamodel datarepository of source and target language metamodel data.
 12. The programproduct of claim 11 wherein the metamodel data in the repositorycomprises invocation metamodel data, application domain interfacemetamodel data, transaction message formatter metamodel data, and typedescriptor metamodel data.